home *** CD-ROM | disk | FTP | other *** search
/ kermit.columbia.edu / kermit.columbia.edu.tar / kermit.columbia.edu / newsgroups / misc.20031118-20041115 / 000364_jaltman2@nyc.rr.com_Thu Aug 19 10:06:28 2004.msg < prev    next >
Internet Message Format  |  2004-11-14  |  3KB
  1. Path: newsmaster.cc.columbia.edu!newsfeed1.nycmny01.us.to.verio.net!nntp2.tagonline.com!newsfeed2.dallas1.level3.net!news.level3.com!bloom-beacon.mit.edu!ra.nrl.navy.mil!HSNX.atgi.net!cyclone-sf.pbi.net!216.196.98.144!border2.nntp.dca.giganews.com!nntp.giganews.com!cyclone1.gnilink.net!gnilink.net!cyclone.rdc-nyc.rr.com!news-out.nyc.rr.com!twister.nyc.rr.com.POSTED!53ab2750!not-for-mail
  2. Message-ID: <41240394.2080502@nyc.rr.com>
  3. From: Jeffrey Altman <jaltman2@nyc.rr.com>
  4. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803
  5. X-Accept-Language: en-us, en
  6. MIME-Version: 1.0
  7. Newsgroups: comp.protocols.kermit.misc
  8. Subject: Re: Firewall Issue
  9. References: <417dde32.0408180838.7d3d74ef@posting.google.com> <41238A69.4070205@nyc.rr.com> <417dde32.0408181353.ad47f9a@posting.google.com>
  10. In-Reply-To: <417dde32.0408181353.ad47f9a@posting.google.com>
  11. X-Enigmail-Version: 0.84.2.0
  12. X-Enigmail-Supports: pgp-inline, pgp-mime
  13. Content-Type: text/plain; charset=us-ascii; format=flowed
  14. Content-Transfer-Encoding: 7bit
  15. Lines: 39
  16. Date: Thu, 19 Aug 2004 01:32:54 GMT
  17. NNTP-Posting-Host: 24.193.46.55
  18. X-Complaints-To: abuse@rr.com
  19. X-Trace: twister.nyc.rr.com 1092879174 24.193.46.55 (Wed, 18 Aug 2004 21:32:54 EDT)
  20. NNTP-Posting-Date: Wed, 18 Aug 2004 21:32:54 EDT
  21. Organization: Road Runner - NYC
  22. Xref: newsmaster.cc.columbia.edu comp.protocols.kermit.misc:15126
  23.  
  24. FTP works this way.  The server has a standard port for command 
  25. channels, port 21.  The client allocates a random port number to
  26. use when making a connection and then connects to port 21.  If the
  27. client does not randomize its port number then it would be impossible
  28. for two processes on the same machine to connect to the same FTP
  29. server.
  30.  
  31. The data connection depends entirely on which side is being the 
  32. acceptor.  In the original "active" model, the client allocates
  33. a random port number and offers it to the server.  The server
  34. then uses port 20 to connect to the client's port.
  35.  
  36. This does not work through firewalls and NATs.  Therefore, the passive
  37. model was developed.  In the passive model, the server allocates a
  38. random port and publishes it to the client.  The client then allocates
  39. a random port number and connects to the server.  The reason the client
  40. uses a random value is because the server may have a small number of
  41. reused ports.
  42.  
  43. Kermit defaults to the passive model as does almost every other current
  44. FTP client.  FTP servers are assumed to be in public space; the FTP
  45. client is assumed to be in private space given the current Internet
  46. architecture.
  47.  
  48. Jeffrey Altman
  49.  
  50.  
  51. Don L wrote:
  52.  
  53. > I'm waiting for some clarification on what they mean by "random high
  54. > ports", but I suspect they are talking about the command and data
  55. > ports the client PC is selecting and not those of the FTP server.  If
  56. > my understanding is correct, the client PC can randomly assign its own
  57. > command and data ports.
  58. > 
  59. > If this is the case (they are talking about the client PC's ports), is
  60. > there a way to assign the command and data ports of the client PC
  61. > using Kermit?
  62.